Comparisons for Teff = 5750, logg = 4.5, and M_H = 0 to MARCS are below. They depends somewhat on radiative transfer keywords, specifically tau_scheme.

compute_magnitude(marcs_flux,marcs_wave,DECam_g_trans,DECam_g_wave)
compute_magnitude(ex_spec.flux./(1e8),ex_spec.wavelengths,DECam_g_trans,DECam_g_wave)

The results are:

• -38.130 MARCS
• -38.156 default Korg
• -38.155 (I_scheme="bezier")
• -38.121 (tau_scheme="bezier")
• -38.121 (I_scheme="bezier", tau_scheme="bezier")

The comparison using default radiative transfer parameters over the DECam g-band is below, with Korg in blue and MARCS in red.

Summary, MARCS and Korg differ for solar on the order of 26 mmag, but slightly different radiative transfer treatments within Korg differ by 35 mmag.

I have computed over a large marcs grid the difference in the photometry. Please request plots @ajwheeler. The simplest thing I made was just M_H = 0, A_M = 0, difference in g-band mag.

Adam will like the linear scale, that shows nothing until temperatures below 4k. I like the log scaled plot so you can see how many mmag difference there is, though cases that go up to at most -10 mmag are dropped by the log. Thoughts? More slices?

So, I lied, and have more plots. I created an interesting representation where I map this ~ 4D grid onto 2D using

marcs_x = marcs_teff .+ 100 .*marcs_a_m
marcs_y = marcs_logg .+ 0.1 .*marcs_m_H

I think we should be worried anywhere there is a change in > 10-20 mmag. @ajwheeler thoughts?

I also did one color

Part of me thinks a lot of this is explained by the lower res of the marcs spectra being just not great for the cooler stars, but I think it is worth trying to make sure we understand and trust metallicity/alpha behavior or have a path to validate it if we are worried.

Part of me thinks a lot of this is explained by the lower res of the marcs spectra being just not great for the cooler stars, but I think it is worth trying to make sure we understand and trust metallicity/alpha behavior or have a path to validate it if we are worried.

Agreed that it's good to express healthy skepticism towards both codes. What linelist did you use for this? It mildly surprises me that the metal-poor stars are worse.

I guess you could ask me to repeat the test synthesizing at the MARCS wavelength resolution using Korg and comparing.

To answer your question
lines = Korg.get_VALD_solar_linelist()

Synthesizing on the MARCS wavelength grid is a pretty good idea, but I don't think that's main source of the disagreement here. I'd bet with high confidence that it's the linelist, which will have hardly any molecular lines. I would expect that to mess up the cool stars substantially.

What's happening with the metal-poos stars is another Q. I see no reason why resolution effects would impact them differently, so there must be something else going on. Off the top of my head, it might be the lack of true scattering in Korg.

Quick Q: get_radius is currently not used anywhere. Do I compute with compute_mags then adjust with the radius?

That is the idea. If the units in compute_mags were right, you would just use the get_radius to convert to the correct unitful absolute magnitude. However, while the units in get_radius are right, I think the units in compute_mags are not (they are fine for colors, but someone needs to revisit them for them to combine with get_radius to give the correct absolute magnitude).

@schlafly

That's pleasantly good agreement for the g-r colors of blue-ish stars. Here's the relevant comparison from Schlafly+2011 (sorry, old!). There colors start to run away at the ~0.1 mag level in g-r at about 4500 K, but are pretty good (~0.01 mag?) for warmer temperatures. I think I read this agreement to be a little worse than that.
https://iopscience.iop.org/article/10.1088/0004-637X/737/2/103#apj398709f2

@schlafly Thanks for pointing to that figure. I am not exactly sure that I think the plot in this PR looks "a little worse." But it isn't really apples-apples I guess.

One comment is that in your paper, you are comparing observed-MARCS_predicted and here I am plotting MARCS-Korg. So I would expect observed - Korg to be roughly (observed-MARCS) + (MARCS-Korg).

It seems to me like for the 4500-4000K region, (observed-MARCS) = -0.1 and (MARCS-Korg)= 0.1 for approximately solar metallicity. That is very rough, but just to say that the signs seem to work out in a compensating way, such that the deviation of MARCS and Korg could be a good thing. This might mean I should grab some real, unredened photometry and try to make these plots.

Yes. It's hard for me to estimate from the colors of the points; happy to go with your eyeballs rather than mine. It's also worth adding that for the comparisons with observed data one relies on the calibration of the spectroscopic parameters; for this kind of analysis, it was never clear to me to what extent the residuals in the photometry were driven by imperfect synthetic spectra vs imperfect stellar parameters.

Noting that I intend to return to this when I have an easy story for a built-in realistic optical linelist and that I am following the discussion.

Sorry, I am late to this party, but I too have been testing the photometric predictions based on Korg models compared to our in house C3K (Kurucz/SYNTHE) grid predictions. I am currently doing this as a post-processing step using Ben Johnson's SEDpy code. I have bolometric corrections computed for many different filter systems including future ones like Roman, SPHEREx, and LSST. I can provide more details and some comparison numbers if people are interested.

I am very interested. If the validation is sufficient, it might be good to try to get this merged.

I'd be very interested to see any comparisons.

I'm happy to merge this regardless of how accurate Korg's SEDs are, what's holding it up for me is that I really want to avoid breaking changes to the API, and I don't think this has an interface that's sufficiently streamlined yet. (Obviously something that would be good for me to work on.)

Just to give you a bit of background, in order to do an apples-to-apples comparison between Korg and our C3K grid of synthetic spectra (our current grid uses Bob Kurucz's SYNTHE), I have been able to hack together a bunch of python/Julia code that allows me to run Korg using our in house ATLAS-12 model atm's and the full Kurucz line list (~270M transitions). I am in the process of running a full Korg grid (~35K total spectra) at R = 150K from 0.3-5.0µm. This grid will be called CWC (Cargile, Wheeler, Conroy).

To check on the photometric prediction consistency between C3K and CWC, I took the most solar-like model (Teff = 5750, log(g)=4.5, [Fe/H]=0.0,[⍺/Fe]=0.0) in both grids, and generated bolometric corrections and colors for various different photometric systems using Ben Johnson's SEDpy code. So the only difference in the following analysis is SYNTHE versus Korg.

Below is a plot showing (top panel) the difference in the computed bolometric corrections for a suite of filters, (middle panel) the difference in the predicted solar flux spectrum (convolved to R ~ 100), and (bottom panel) the predicted colors compared to our best estimate of the observed solar colors. The observed "solar colors" are actually based on studies of a bunch of solar-twins (Ramirez et al. 2012, Casagrande et al. 2012, Casagrande & VandenBerg 2018), but that is what we have to work with.

It is clear there are differences between these synthetic flux spectra. The difference in the bolometric corrections almost looks like some type of continuous opacity source? But the promising thing for Korg is when comparing the solar predicted to empirical colors, Korg seems to be more accurate than SYNTHE for most colors, so a win for Korg! It would be interesting to see if these offsets are similar to what you see when comparing Korg to MARCS, let me see if I can put this together...

Thanks @pacargile, this is really interesting.

the difference in the bolometric corrections almost looks like some type of continuous opacity source?

Agreed, although I'm looking at the solar spectra to draw that conclusion.

@pacargile Does C3K go absolutely crazy at the red end?

We might be able to integrate with https://github.com/JuliaAstro/PhotometricFilters.jl, which would make this way simpler.

@pacargile Does C3K go absolutely crazy at the red end?

@andrew-saydjari Sorry, just saw that you asked this question. I'm not sure what you mean by "crazy at the red end", but one thing that is becoming very apparent from testing our new Korg-based models against newly downloaded SPHEREx data is they are more accurate from 1-5um (even with the same atm and linelist used in C3K). I'm not entirely sure why yet, perhaps something about better continuous opacities in the IR in Korg?

Table 1 in the first Korg paper lists all the continuum opacity sources in the IR, and Figure 3 shows which are important in the IR. The treatment of H- ff opacity is the likely cuprit. Korg is using Bell & Berrington 1987, which is probably more recent that what ATLAS does (but I'm not sure).

We might be able to integrate with https://github.com/JuliaAstro/PhotometricFilters.jl, which would make this way simpler.

I'm working on a PR to overhaul PhotometricFilters.jl to get it ready for registration here and we've added a feature to query the SVO database for filter transmission curves which should be convenient for automating a pipeline to compute synthetic photometry. If you all have any feedback on the design I'm happy to hear it -- we're presently not happy with the names of a few methods so some help there might be useful.

I also maintain the BolometricCorrections.jl package which provides an interface to pre-computed tables of BCs. I currently have the MIST BC tables, am almost done with a PR adding the YBC bolometric corrections, and am waiting to receive updated files for the BaSTI BC tables as well. I would be happy to add your BCs to this package when they are published @pacargile, and hope the package might provide an easy way for you all to check new BCs derived with Korg against these published BC tables.

@cgarling I am trying to get this merged. Can you update on the status of the filters and BC packages? I don't see a release for the filter curves for example.

The SVO functionality for PhotometricFilters.jl, which retrieves filter curves and metadata like photometric zeropoints, is basically final and we are just trying to figure out some API stuff (what to name methods) before merging #22 and publicly releasing. The package includes things like interpolating the throughput as a function of wavelength and calculating some statistics (like mean flux density, currently method called integrate). Much of what you have in photometry.jl here is already in PhotometricFilters.jl. It should therefore be possible to reproduce something like your compute_magnitude relatively straightforwardly. I was intending to implement something myself but got lost looking into the conventions for properly zeropointing ST vs Vega vs AB mags (I don't work on spectra myself).

BolometricCorrections.jl is already public and the stable version includes MIST BCs only. Currently the main branch and the PR #14 implementing the YBC grid are nearly final, but use git-lfs for managing the data source. So the main branch should work if you have a valid git-lfs executable on your PATH but I am working on merging this PR to add git-lfs support to Git.jl so users don't have to worry about installing it themselves.

Yeah, this afternoon I have refactored to accept filter curves from PhotometricFilters.jl, but I also want to accept users coming with their own wavelengths and throughputs, so I decided not to rely on the interpolation methods that come with the PhotometricFilter type.

@ajwheeler may want to wait to merge this until PhotometricFilters.jl is actually released though?

For some reason that I am struggling to resolve, even with PhotometricFilters loaded, I can't get the PhotometryExt module to export its functions. Still a draft, though maybe we can resolve in some free time during the hack week. It is at least partially to do with the fact that PhotometricFIlters.jl is not a registered package... so maybe I should just hold my horses.

I think the most common pattern is to define a function in the parent module that is imported into the extension and extended with new methods. Exporting newly defined symbols from extensions can be tricky. This section of the docs may be helpful.

If you wanted, I think you could merge something more like what you had before -- then when we register PhotometricFilters.jl I could submit a PR to extend compute_magnitude to take our types.

I have now added zeropoint calculations and synthetic photometry to the PhotometricFilters.jl PR that you may wish to review.